In data communication environments, such as a distributed network, many different vendors provide a number of products for specific services. Heretofore, a predetermined set of domain-specific protocols has been required to be specified to enable arbitrary components in the environment to communicate with each other, assuming the components were transmitting or receiving data, hereinafter referred to as (“transferring data”). For example, a device manufactured by one vendor would have difficulty communicating with a device manufactured by another vendor without using the predetermined set of protocols mentioned above. The problem of different vendors requiring different predetermined protocols has been partially dealt with by adopting existing protocol standards. However, there are different standards organizations and thus different protocol standards.
When arbitrary components such as computer applications or programs, data, memory, file directories, individual files, printer devices, cellular telephones, facsimile machines, copier machines, scanner devices, desk-top computers, lap-top computers, personal digital assistant (“PDA”) systems, or any other device, for example, attempt to communicate without having a priori knowledge of each other, particular domain-specific protocols, such as the file system domain (e.g., NFS and CIFS) or the printer domain (e.g., IPP and LPR), must be known a priori by both parties to successfully communicate. An arbitrary component, such as a PDA attempting to communicate with a file system, or a printer device attempting to do the same, must be explicitly programmed to understand one or more of the standardized protocols mentioned above. An example includes a computer device or application having to be programmed to understand a printer device by installing a domain-specific printer driver. If the device or application is programmed to understand how to communicate and use a printer device, generically, the driver will only enable the device or application to access a particular type of printer device and not the universe of all printer devices. Thus, when new and unknown components enter the equation, the application must be reprogrammed to understand the new standardized protocols used to communicate with the new components. Referring to the above computer and printer device example, if a new type of printer were introduced, the computer device would have to be re-programmed to be able to transfer data with the new printer device by installing a printer driver specific to the new printer device. Thus, each application must be explicitly written to use a particular set of standardized protocols prior to communicating with the components associated with the protocols.
In a system such as Jini™, developed by Sun Microsystems of Palo Alto, Calif. and described in “A collection of Jini™ Technology Helper Utilities and Services Specifications,” Palo Alto, Calif., Sun Microsystems, Inc., pp. 1-214, 2000; and “Jini™ Technology Core Platform Specification,” Palo Alto, Calif., Sun Microsystems, Inc., pp. 1-126, 2000, which uses domain-specific interfaces, for a component such as a PDA system to communicate with another component such as a printer, the PDA system must contain a priori knowledge of the semantics of the printer's programmatic interfaces. In other words, a component that knows how to print still might not know how to transfer data between a file system and a scanner device or a network translation service until it is explicitly programmed to know how to communicate with the interface for the particular components.
Currently, ubiquitous computing environments do not allow for the network effect. That is, as additional components are added to the environment, they do not have the capability to do more than add the capability of that new component to the environment. It would be advantageous to provide some mechanism where the addition of components in an environment enhances the operation of the components in the environment.
Additionally, some systems maintain contextual information in an ad hoc manner with respect to the components within the system. Such contextual information is often represented in various formats depending on the type of component it represents, such as whether the component is a user, a document or an application. This often makes it difficult or impossible for arbitrary components within a system to provide each other with current contextual information, particularly if the arbitrary components do not have a priori knowledge of each other.
One problem with contextual systems is that of establishing credibility (for example, verifying that a property value has not been inappropriately changed). Another problem is that it is very difficult to understand system behavior in a ubiquitous computing environment because the environment is so fluid. It would be advantageous to be able to verify how a property value changed and why the system behaved in a particular way.
One problem using discovery mechanisms in ubiquitous computing environments is that these mechanisms often return very long lists of the discovered components without providing information to assist a user in understanding and selecting the useful components for the current situation. It would be advantageous to preferentially provide the user with information that is relevant to the current situation.